AWS CDK (Cloud Development Kit) 를 소개합니다 #aws #awscdk #aws입문

안녕하세요! 클래스메소드 주식회사 의 김태우입니다.

요즘들어 AWS CDK 라는 서비스에 대해 이야기 나누시는 분들이 많아지는 것 같습니다. 초기버전부터 빠르게 업그레이드가 1년이상 계속되고 있던 터라 저도 안정되기 시작하면 한번 봐둬야지라는 생각에 공부를 미뤄왔었는데요, 요즘에는 꽤 쓸만한 정도(라기보다는 정말 좋은)라는 느낌을 많이 받아서 이번 블로그에서 여러분들에게 소개해보고자 합니다! :)

그럼, 시작하겠습니다~!

TL;DR

import * as cdk from '@aws-cdk/core';
import * as lambda from '@aws-cdk/aws-lambda';
import * as apigw from '@aws-cdk/aws-apigateway';
import { HitCounter } from './hitcounter';
import { TableViewer } from 'cdk-dynamo-table-viewer';

export class CdkWorkshopStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const hello = new lambda.Function(this, 'HelloHandler', {
      runtime: lambda.Runtime.NODEJS_10_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'hello.handler'
    });

    const helloWithCounter = new HitCounter(this, 'HelloHitCounter', {
      downstream: hello
    });

    new apigw.LambdaRestApi(this, 'Endpoint', {
      handler: helloWithCounter.handler
    });

    new TableViewer(this, 'ViewHitCounter', {
      title: 'Hello Hits',
      table: helloWithCounter.table
    })
  }
}

위 코드를 아래 명령어를 통해 CloudFormation 템플릿으로 자동변환하여 AWS 환경으로 배포할 수 있습니다.

$ cdk deploy

AWS CDK 란?

AWS CDK(Cloud Development Kit) 란 IaC(Infrastructure as Code) 서비스의 한 종류로, 기존 시장을 장악하고 있던 Terraform, AWS CloudFormation 등과 비교할 수 있습니다.

Ansible 이나 Puppet, Chef 등과 같은 툴도 IaC 서비스로 많이 분류되었던 것 같으나, (개인적인 의견이지만) 요즘에는 IaC 보다는 Provisioning(프로비저닝) 툴에 속하는 도구들이 아닐까 생각합니다.

엄밀하게 이러한 서비스나 툴을 나누는게 무슨 의미가 있나 싶기도 하지만, 처음 이러한 서비스 및 도구들을 접하시는 분들의 경우, 각 서비스나 툴의 차이점을 빠르게 파악하기 위해서 되도록 정확한 명칭으로 분류함으로써 러닝커브를 줄이는데 도움을 줄 수 있지 않을까 합니다.

Proviosioning 툴에 속하는 Ansible, Chef, Puppet 등의 도구들은 기본적으로 "비교적 OS 레벨에서의 세팅에 최적화" 되어있는 툴들이 아닐까 생각합니다. 따라서, Terraform 이나 AWS CloudFormation 등과 비교하면 사실 인프라 자체에 대한 지원은 없거나 미약하고, 각종 미들웨어 인스톨/업데이트 관리, OS 환경변수 등의 세팅 등을 주 목적으로 많이 사용하게 됩니다.

그렇다면 IaC 로 분류된 Terraform 이나 AWS CloudFormation 등의 어떤점이 부족했길래 AWS CDK 가 새롭게 출시된걸까요? AWS CDK 에 대해 설명하기 전에 이러한 서비스들에 대해 잠깐 정리를 하고 넘어가려고 합니다.

IaC 서비스/툴에 대한 간단 정리

Terraform

AWS, GCP, Azure 를 포함한 다양한 클라우드 및 SaaS 서비스의 구성을 코드형태로 "선언적"으로 작성할 수 있는 IaC 도구입니다. AWS CloudFormation 보다 신규서비스에 대한 지원이 더 빠르게 적용된 적도 있기도 하고, 멀티 클라우드 구성에서는 거의 보편적으로 사용되고 있는 듯 합니다.

CloudFormation

일종의 AWS 서비스의 바이너리코드 같은 개념으로, Terraform 과 달리 AWS 서비스만을 대상으로 합니다. AWS 가 공식적으로 제공해주는 툴인 만큼 신뢰할 수 있고, 사용하면서 AWS 의 각 서비스들에 대해 더욱 깊이있는 이해가 가능해지기도 하며, AWS 생태계에 빠르게 적응할 수 있도록 도와주는 부가가치가 있는 툴이라고 생각합니다. 그러나 초반에 가독성 등의 이유로 Terraform 을 선호하는 사람도 많이 있는 듯 합니다.

CDK

Terraform 이나 CloudFormation 은 코드로 인프라를 작성할 수 있다는 장점은 있었지만, "프로그래밍" 코드가 아닌 YAML 이나 자체적인 문법을 따라야 하는 등의 제약이 있었던데에 반해, CDK 는 Typescript, Python 등의 범용 프로그래밍 언어로 IaC 가 가능합니다. 이러한 방식이 왜 이렇게 요즘 뜨고 있는가에 대한 설명은 이번 포스팅의 다음 챕터부터 설명드리겠습니다 :)

Pulumi 등 기타 IaC 서비스/툴

사실 다른 서비스나 툴들은 제가 직접 사용해본 적이 없어서 뭐가 어떻고 저렇다 하기엔 어렵지만, CDK 이전에도 범용적인 프로그래밍 코드로 인프라를 정의해보자라고 하는 시도는 있었습니다. 대표적으로 Pulumi 가 그 예인데요, Python 으로 인프라 정의가 가능한 참신한 서비스였습니다만, 현재는 Typescript 등의 언어도 지원하는 듯 합니다. 사용성이 어떨지는 잘 모르겠지만 AWS 이외의 멀티 클라우드를 고려하고 계신분이라면 범용 프로그래밍 언어로 인프라를 작성하고 싶으신 경우 한번 살펴보는 것도 좋을 것 같은 서비스일 것 같습니다.

AWS CDK Workshop

AWS CDK 를 직접 실습해보면서 어느정도 깊이있는 이해를 할 수 있도록 워크샵 페이지가 공개되어있다는 거, 알고 계셨나요?ㅎㅎ 저도 직접 따라해보면서 짧은시간동안 굉장히 유익한 학습이 되었다고 생각했습니다. AWS 및 IaC 에 어느정도 익숙하신 분들은 1시간이면 특정 언어 하나를 선택하여 전체를 다 진행해 볼 수 있을 것 같습니다. 그렇지 않으신 분들, 이러한 개념 자체를 완전히 처음접하시는 분들이라고 하더라고 진행하는 과정에서 자주 일어나는 에러나 문제점 등에 대해서도 부가적인 설명을 해주고 있기때문에, 하루정도면 어느정도 캐치업 할 수 있지 않을까 생각합니다.

본 포스팅을 가볍게 훑어본 다음, 아래의 워크샵을 꼭 진행해보시는 것을 강력히 추천합니다!ㅎㅎ

AWS CDK Workshop 페이지로 이동

AWS CDK 에 대한 AWS Builders 세션 소개

AWS 코리아의 김현수 솔루션즈아키텍트님께서 발표해주신 영상입니다. 사실 이거 하나만 봐도 CDK 가 무엇인지 거의 감을 잡으실 수 있을거라 생각합니다. 한번쯤은 꼭 봐두시는 것을 추천합니다!

AWS CDK 에 대한 다른 블로그

제가 이 글을 쓰는 시점에 이미 CDK 에 대해 소개하고 있는 한국어 블로그도 다수 존재했습니다.

• AWS CDK로 lambda와 API Gateway 생성하기 (Typescript)
• AWS CDK Lambda Basic Guide
• 코드로 인프라 관리: AWS CDK
• AWS CDK 란?
• AWS CDK로 서버없이 서비스 운영해보기 (1) - REST API
• AWS CDK 개발 환경 구축하기

따라서, 본 포스팅에서는 AWS CDK 가 무엇인지에 대한 내용보다는 CDK 를 왜 써야하는지, CDK 를 쓰면 어떤점이 좋은지에 대해 중점적으로 소개할까 합니다.

AWS CDK 는 왜 써야하나요?

좋은 질문입니다. 우선 이에 대한 제 답변부터 말씀드리면, "AWS CDK 를 꼭 쓸 필요는 없다" 가 정답에 가깝지 않을까 싶습니다. 조금 극단적으로 이야기한 부분도 있지만, 반드시 인프라를 CDK 를 활용해서 구성할 필요는 없다라는 점을 조금 강조하고 싶었습니다. 즉, 기존 인프라가 Terraform 으로 작성되어 있거나, AWS CloudFormation 으로 작성되어 있던것을 "굳이" CDK 로 재작성할 필요가 없다는 점을 먼저 강조하고 싶습니다.

따라서, AWS CDK 를 왜 써야하는지에 대한 질문보다 "AWS CDK 를 사용하면 어떤점이 좋나요?" 라고 질문하는 편이 더 좋을 것 같은데요, 사실 저도 아직 CDK 를 사용해서 실무에서 프로젝트를 진행해본 적은 없고, 개인적인 용도로 이래저래 사용해봤을뿐이라 어디까지나 제가 "개인적으로" 경험했던 범위에서의 느낀점을 공유드리려고 합니다.

AWS CDK 를 사용하면 어떤점이 좋나요?

1. DX (개발자경험, Developer Experience) 가 확연히 좋아집니다

실제로 CDK 를 사용해보시면, 사실 이게 가장 첫번째로 느껴지는 혜택이지 않을까 합니다. 저는 주로 CDK 는 Typescript 를 사용해서 코드를 작성하는데요, VS Code 와 궁합이 장난아닙니다.

위 스크린샷에서 downstream 을 작성하던 중에 이미 downstream 이 완성된 것이 보이시나요?

해당 부분은 위 스크린샷과 같이 다른 파일에 HitCounterProps 로 정의한 인터페이스를 VS Code 가 참조하여 자동완성 기능을 제공해주는 것을 볼 수 있습니다.

이게 정말정말정말 편리한데요, Terraform 유저들의 경우 사실 Terraform Autocomplete 이라는 툴을 통해 어느정도는 혜택을 받았을거라 생각합니다만, Terraform 의 HCL 은 기본적으로 프로그래밍 언어가 아니기때문에 "완벽한" 수준의 자동완성기능은 많이 어려웠고, 위의 플러그인에 버그가 발생해도 사실 어쩔수 없는 부분이었을 것 같습니다.

하지만, CDK 의 자동완성기능은 그저 해당 프로그래밍 언어를 사용하는 것만으로 자동으로 같이 딸려서 혜택을 누릴 수 있는 기능이기 때문에, 버그나 오작동 등에 대한 염려도 사라지고, 따로 플러그인 관리를 해주지 않아도 디폴트로 지원된다는 점에서 굉장히 강력하다고 할 수 있습니다.

특히, CloudFormation 위주로 많이 작업했던 저같은 분들이 계시다면, CloudFormation 템플릿을 작성할 때, 거의 항상 CloudFormation 도큐먼트를 몇개씩 열어두고 작업을 하는데요, CDK 로 작업하게 되면 자동완성기능에 의해 도큐먼트 의존도가 점점 줄어들것으로 예상되어, 조금만 익숙해져도 획기적인 DX 향상을 기대할 수 있을 것 같습니다.

2. 모듈화가 굉장히 편해집니다

기본적으로 누릴 수 있게되는 자동완성기능 혜택 외에도, CDK 를 활용하면 스택 별로 참조하는 것이 굉장히 직관적이고 간단하게 됩니다. 예를 들어, EC2 스택에서 VPC 스택의 VPC ID 나 Subnet ID 를 참조하고 싶은 경우, 아웃풋 등으로 처리하고 EC2 에서는 해당 VPC 스택의 이름, 리소스 아웃풋이름 등을 통해 리소스를 참조할 수 있었는데요, 이 과정에서 실수가 동반될 가능성이 굉장히 컸던 것에 비해 CDK 를 사용하면 단지 public readonly 프로퍼티를 정의함으로서 스택 간의 참조기능이 매우 직관적이 되며, 거의 실수하기 어려운 환경이 만들어집니다.

이러한 환경이 만들어지면 무엇이 좋은가하면, 프로젝트가 진행됨에 따라 덩치가 너무 커진 스택을 나누거나 스택을 합치는 등의 작업이 매우 편안해진다는 것입니다. 다음에서 설명할 테스트가 가능하다는 점도 스택의 모듈화에 크게 공헌하는 특징이므로, 테스트 쪽도 얼른 살펴보고자합니다.

3. IaC 의 테스트가 쉬워집니다

인프라를 코드로 작성할 수 있다는 것의 장점은 무엇일까요? 바로 git 등을 사용하며 인프라 버전관리, 코드리뷰, 문제 발생시 실수없는 빠른 롤백 등의 작업이 가능해진다는 것인데요, 이러한 코드가 범용 프로그래밍 언어로 바뀐다면 추가되는 또다른 굉장히 중요한 장점으로서는 바로 기존의 테스팅 지식을 활용한 테스트가 가능해진다는 것입니다. 특히, IaC 코드의 유닛테스트만 진행해도 엄청난 효과를 누릴 수 있게된다는 사실을 금방 알아차리실 수 있을 것 같습니다.

반드시 선언되어야하는 리소스, 반드시 설정되어야하는 프로퍼티 등의 유닛테스트를 통해 실수할 수 있는 가능성을 획기적으로 줄일 수 있게됩니다. AWS CDK 의 테스트 관련 도큐먼트 에서는 CDK 를 도입함으로서 아래의 테스트가 가능해진다고 설명하고 있습니다.

• Snapshot tests
• Fine-grained assertions
• Validation tests

꼭 한번 읽어보시는 것을 추천합니다!

4. 오픈소스 참여로 AWS 생태계에 기여할 수 있습니다

음..ㅎㅎ 솔직히 이건 쓸까 말까 망설이다가 적어봤는데요, AWS CDK 는 오픈소스로 관리되고 있는 툴인 만큼 직접 contribute 하는 것이 가능합니다. 저는 아직 눈팅(?)만 하는 수준이지만 저희 회사의 加藤 涼(카토 료)씨는 CDK 에 벌써 두차례나 contribute 하는 등의 활약을 하고 있습니다.

• feat(dynamodb): add metrics for dynamodb table #6149
• feat(apigateway): access logging

점점 더 각광받고 있는 CDK 에 대해서 배우기도 하고, 오픈소스에 공헌도 할 수 있는 절호의 기회가 아닐까 싶습니다!ㅎㅎ

(그러면서 본인은 ..... 먼산....ㅋㅋ)

마무리

본 포스팅과는 별로 관련없는 마무리 글이 될 것 같습니다만, AWS CDK 도 그렇지만 정말 AWS 서비스는 너무 빠르게 발전하고 있는 것 같습니다. 개인으로 캐치업 할 수 있는 수준의 업데이트 속도를 넘어선지 오래되었다고 느끼는 만큼, 많은 분들이 블로그 등을 통해 AWS 에 대한 기술 내용을 공유할 수 있는 문화가 한국에도 정착되었으면 합니다. 그런 의미에서 저도 좀 더 힘내서 열심히 한국어 포스팅 해보고자 마음을 다잡아봅니다ㅎㅎ

조금이라도 이 글이 도움이 되셨길 바라며, 이상, 클래스메소드 컨설팅부의 김태우(@twkiiim) 였습니다! :D